在 BigQuery 的費用監控中，其實大部分都是運算費用居多，儲存費用是占比很小的。

不過我們還是有監控資料表的靜態資訊，看看容量大、又長時間沒有人更新的資料表在哪裡（是誰又偷偷在測試新玩意後放置不管？）這部分與 Cloud Storage 相似，成本或許會是其次，重點是維持資料庫的整潔。

接下來就要講到運算費用的監控啦！

概念上，我們會將 BigQuery 的運算費用分成幾類：

1. Airflow 所觸發的 BigQuery 運算：雖然我們從 BigQuery procedure 搬家到 dbt 來做轉換，但我們仍然有一些工作，會需要在 Airflow 裡直接透過 BigQuery API 來執行工作，通常是要處理 dbt 上游的其他資料表。
2. dbt 的運算：每天定期更新的 dbt 的資料模型、CI/CD 所觸發的運算，都應該歸在此類。
3. 在 BigQuery 中進行的運算：工程師們、其他資料使用者們都可以直接在 BigQuery 寫 SQL code 來運行。
4. 在 Metabase 中進行的運算：dbt 的下游，我們會用 dbt 的資料模型於 Metabase 中建立各式各樣的儀表板，業務單位通常會在 Metabase 中取用這些資料或圖表，過程中也會有不少運算發生。
5. 其他微服務中進行的運算：有一些小型的 API 服務，我們會拿 BigQuery 作為該服務的資料庫，通常是比較輕量的功能，否則這個做法，我想並不是原本 BigQuery 期待提供的功能（效率跟費用都不是這麼適合）

而我們要怎麼找出這些類別，分別去看出是誰花的錢呢？

1. GCP Billing：首先，我們可以在 Google 的帳單中看到 BigQuery 中運算費用的資料，除了時間、費用、運算量之外，並且它有包含一些標籤資訊，後續可以跟 BigQuery 提供的 Metadata —— INFORMATION_SCHEMA（文件）做串接。
2. INFORMATION_SCHEMA：這裡面真的有非常多資訊，是相當好用的 Metadata，在這裡，我可以知道是哪個 service account 所觸發的運算，也可以知道它執行的任務類型、query 所使用的 SQL code，而 dbt 的任務資訊更詳細，用 dbt 所進行的運算，還會包含該任務中上游的 reference table，目標的 destination table，我可以知道它取用了哪些資料表，用以建立的資料表。
   而另一點是 Metabase 的運算中有新增一些 pattern，在 query 內容中新增一些註解，只要搭配 Metabase 資料庫中的一些紀錄，就可以讓我們可以知道是誰、哪個儀表板在進行運算的。

就是如此，基本上靠這兩個資料源，我們就可以知道運算是從哪裡發生的！

什麼服務在使用、誰在使用，有沒有哪些地方突然有大量的運算需求，誰這個月突然使用特別多（哦？很認真工作喔？）

由於這些資料轉換都是透過 dbt 的資料模型來處理，可以加上 testing 來讓我們及時捕捉到異常的使用行為！

對於在意費用的團隊，我想這應該是蠻必須的工程。

除了異常行為之外，我們也可以看到下游業務單位中最常使用的儀表板有哪些，進而去反思在資料需求上的處理政策（不要看一個人問了什麼，要看一個人做了什麼）。要是有人提了各式各樣的需求，理由寫得天花亂墜，結果最後做出來的儀表板每張都沒看幾次，我們就知道這是真需求、還是假需求了。